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Abstract. This paper presents a proposal for a flexible agent mobility architec- 
ture based on IEEE-FIPA standards and intended to be one of them. This pro- 
posal is a first step towards interoperable mobility mechanisms, which are needed 
for future agent migration between different kinds of platforms. Our proposal is 
presented as a flexible and robust architecture that has been successfully imple- 
mented in the JADE and AgentScape platforms. It is based on an open set of 
protocols, allowing new protocols and future improvements to be accommodated 
in the architecture. With this proposal we demonstrate that a standard architecture 
for agent mobility capable of supporting several agent platforms can be defined 
and implemented. 
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1 Introduction 

Mobile agents are software agents with the ability of travelling from one execution 
environment (platform) to another across a computer network 1 19 1. Their introduction 
and studying during the last decade have opened an interesting research field with new 
applications lfT8l and paradigms. Unfortunately, mobile agents have also raised some 
issues regarding security 1101171 and interoperability [16], which are still unsolved. 

The basic operations behind an agent migration are suspending the execution of 
the agent in its current execution platform, transferring the agent code, data and state to 
another platform, and resuming the execution of the agent in the same state it was before 
the migration took place. The actual migration is far more complex, since there are 
many issues that must be taken into account, ranging from security and access control 
mechanisms to interoperability of different hardware, languages, and agent platforms. 

Several contributions in the agent mobility field have been made comprising dif- 
ferent agent platforms such as Aglets 1111 . D'Agents [8|, or Ara lfT5l just to mention 
some. Despite the number of proposed and developed mobile agent platforms, they hap- 
pen to be incompatible between them. In an attempt to solve, or at least to minimise, 
the problem of incompatibility and interoperability some organisations have driven the 
development of standards. The first effort was the OMG-MASIF [12] specification writ- 
ten by the OMG group, an attempt to standardise mobile agent APIs. The second, and 
most popular nowadays, was taken by the IEEE-FIPA organisation, which created sev- 
eral specifications related to agent communications B7I41 . including even one for agent 
mobility [3 | that was deprecated due to a lack of implementations. 



Besides standardisation, several interesting works have recently appeared in the 
field of agent mobility. One of this works is the Kalong architecture [2], a mobility mod- 
ule used in the Tracy platform which is exportable to other platforms [14]. It is a com- 
plete migration system on its own, using different techniques to optimise the agent code 
transfer. Nevertheless it is not based on any known standard. Another interesting work 
is the AgentScape Operating System iTPJll . which is a mobile agent platform focused in 
scalability and security. It has a separate subsystem which can register and move agent 
code and data, making them usable for other platforms. However, AgentScape does not 
pursue the standardisation of agent facilities. And finally, there is our previous contri- 
bution to the field of mobility, which is the implementation of a mobility service for the 
JADE platform [9] following IEEE-FIPA specifications [1 1. This one is currently being 
used by the whole community of JADE users, and it is the basis for the work described 
in this paper. This mobility service is very rigid and requires a fixed set of protocols, 
which might not be suitable for all situations. This paper presents a new proposal for 
the future standardisation of a flexible agent migration process as a new IEEE-FIPA 
specification. The aim of this proposal is twofold. Firstly, it sets the foundations for an 
interoperable migration among different agent platforms. Secondly, it tries to be com- 
pletely flexible allowing the integration of future migration protocols. 

The paper is organised as follows: Section|2]shows a brief description of the former 
migration; Section [3] describes the new migration proposal; and Section [4] presents a 
simple transfer protocol for the first implementations. Finally, Section [5] summarises 
our conclusions and future work. 



2 Former migration 



The proposal of the migration architecture presented in this paper is the natural evolu- 
tion of the work presented in [ 1], a simple inter-platform mobility service implemented 
over the JADE agent platform. That former proposal was partially based on the FIPA 
Agent Management Support for Mobility Specification [3], and followed the FIPA- 
Request Interaction Protocol [6| with two steps: a first one to transfer the agent, and a 
second one to start it. Figure[T]illustrates its sequence of messages. 
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Fig. 1 : FIPA-based mobility protocol. 



The purpose of this first implementation was to experiment with the old FIPA spec- 
ification, to identify drawbacks, to evaluate the performance of an ACL-based mobility 
and to evaluate its flexibility for interoperating with different types of platforms. 



3 Multi-protocol based architecture proposal 

Our proposal defines a new architecture to migrate agents among platforms using some 
of the agent communication standards proposed by the IEEE-FIPA organisation. This 
proposal aims a double objective. On one hand, it tries to set the grounds for an inter- 
operable migration between different types of agent platforms. On the other hand, it 
defines a flexible framework in which future migration protocols will seamlessly inte- 
grate. 

The migration process is split into five different steps contained inside a Main proto- 
col that follows an IEEE FIPA Request Interaction Protocol (see Figure 0, which form 
together the whole migration process (this is illustrated in FigurelUl. The same ontology 
is shared by all protocols in the proposal: the migration-ontology. All the architecture 
is managed by an agent called amm (Agent Mobility Manager). 





Fig. 2: FIPA Request Interaction protocol. Fig. 3: FIPA Proposal Interaction protocol. 



The steps proposed for the migration process are: Pre-Transfer (s pr e-tra,nsfer), 
Transfer (s transfer ), Post-Transfer (s post -transfer), Agent Registration (s 

registration) 

and Agent Power Up (s powerup ). Each one of the first three steps is implemented by 
an open set of protocols that is specified in the first sent message. These protocols are 
out of the scope of this proposal. The last two steps (registration and powering up) are 
implemented by two fixed protocols, defined later, which are mandatory in all platforms 
supporting this proposal. Each migration process must execute all the steps in the listed 
order. 
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Fig. 4: Whole migration process. 



Each one of the above mentioned protocols: must have a well defined functionality 
suitable with one of the steps; is independent from the rest; can be composed of many 
stages; should use one or more ontologies and interaction protocols; and must have a 
well-known name. 

Since this proposal is intended to be a new IEEE-FIPA standard, it uses several of 
the current specifications of this organisation. First of all, the mobile agent conforms 
to the IEEE-FIPA Agent Management Specification Q, with the standard lifecycle and 
the agent naming conventions defined there. Furthermore, all the messages used in this 
proposal rely on the ACL Message specification defined in [4| and take advantage of 
using IEEE-FIPA Interaction Protocols. These protocols are used because they provide 
a more consistent message exchange between the involved platforms and, moreover, 
because they reflect and delimit the different parts comprising the migration. Note that 
although the aim of this architecture is to use the IEEE-FIPA specifications and its inter- 



action protocols, developers are free to implement their own protocols using alternative 
technologies. 



3.1 Main protocol 

The Main protocol starts the migration process and manages the rest of protocols. As 
mentioned before, the whole migration process follows an IEEE-FIPA Request Interac- 
tion Protocol [6 1 (see Figure|5). The first message sent by the initiator requests the des- 
tination platform to start the process. It contains a move or clone action (see Tabled 
together with the Mobile Agent Description (see Table [2j, which contains information 
about the agent compatibility and the set of protocols to be used, including the Mobile 
Agent Profile used as defined in Q. Furthermore, a unique session ID is generated to 
uniquely identify the whole migration process. 

An immediate response is received from the receiver agreeing or refusing the migra- 
tion request (aborting the whole migration in this last case). In case of agreement both 
participants collaborate by running the specific migration steps they have agreed (each 
one using the protocols requested in the previous clone or move action). Finally, the 
result of the whole migration process is received by an inform or a failure mes- 
sage. It should be noted that a migration process is considered failed when any protocol 
in any of its steps fails. 



Function 


move / clone 


Ontology 


migration-ontology 


Supported by 


amm 


Description 


Request to start an agent migration/cloning process. 


Domain 


mobile-agent-description 



Table 1: Migration Ontology: Move / Clone action 



Frame 


mobile-agent-description 


Ontology 


migration-ontology 


Parameter 


Description 


Presence 


Type 


name 


The agent identifier 


Mandatory 


agent-identifier 


agent-profile 


List of agent requirements. 


Mandatory 


mobile-agent-profile 


agent-version 


Agent version. 


Optional 


String 


pre-transfer 


Pre-transfer protocols chosen 


Optional 


Set of String 


transfer 


Transfer protocols chosen 


Mandatory 


Set of String 


post-transfer 


Post-transfer protocols chosen 


Optional 


Set of String 



Table 2: Migration Ontology: Mobile agent description 



3.2 Pre-Transfer, Transfer and Post-Transfer steps 

The flexibility of our architecture comes from the Pre-Transfer, Transfer, and Post- 
Transfer steps. In each migration process, a subset of protocols are chosen and specified 
by the migrating agent in the initial request message. If the migration is agreed, 
then the protocols are executed in the same order as specified in the first message. 
The general functionality of these protocols is defined by this proposal, but the specific 
protocols must be proposed and standardised apart. At least one transfer protocol should 
be provided to do a complete migration (one is proposed in Section|4] 

The three steps revolve around the transfer of the agent, which is the central part of 
a migration process. Next, a brief description of these steps follows: 

- Pre-Transfer: In this step the set of protocols needed before the agent transfer is 
run. The protocols used in this step can be related to authentication, authorisation, 
resource agreement, etc. For a specific migration, there can be zero or more pre- 
transfer protocols. 

- Transfer: The set of protocols to transfer the agent code, data and state is run in 
this step. Different kinds of protocols allow to follow different migration strategies 
(push, on demand, etc.). There should be at least one transfer protocol in this step. 

- Post-Transfer: In this step the set of protocols needed after the agent transferring 
is run. The protocols in this step can be used for authorisation, agent data transfer, 
etc. This step can have zero or more post-transfer protocols. 

3.3 Agent Registration step 

In the Agent Registration step (s reg i S tration), the agent is rebuilt and registered in the 
destination platform. Then, if the registration is successful the agent should be killed on 
the origin platform. 

In this case only one pre-defined protocol is allowed to be used, the Agent Regis- 
tration Protocol (pregistration), identified by the "registration-protocol-vl" string. 

This protocol uses the simplified IEEE-FIPA Request Interaction Protocol where 
the agree and refuse messages are not used. The first message contains the agent 
identifier to be registered over the register action (see TableO. Then, as a result, it 
is expected an inform-done message if the operation succeeds or a failure one 
otherwise. In the first case, the agent in the source platform should be killed. 



Function 


register / power-up 


Ontology 


migration-ontology 


Supported by 


amm 


Description 


Request to register / power-up an agent in a remote platform. 


Domain 


agent-identifier 



Table 3: Migration Ontology: Register / Power Up action 



3.4 Agent Power Up step 

In the Agent Power Up step (s power - up ), the destination platform is requested to resume 
the execution of the received agent. Only one protocol is allowed to be used here, the 
Agent Power Up Protocol (p powe r-up)< identified by the string "power-up-protocol-vl". 

This protocol also uses the simplified version of the IEEE-FIPA Request Interaction 
Protocol. The first message contains the power-up action (see Tabled and the agent 
identifier, in order to confirm the agent to start. Then, an inf orm-done is returned 
if the agent has been correctly started in the destination platform, or a failure if an 
exception has been thrown. 



4 Push Transfer Protocol 

This section presents the Push Transfer Protocol, proposed outside the main architecture 
of the migration process. This transfer protocol is based on the simple transfer protocol 
presented in the former migration mechanism explained in Section|2] It is identified by 
the "push-transfer-protocol-vl" well-known name. 

It is called Push Transfer Protocol because all the agent code along with the agent 
data and state (this last one only if needed), is directly sent from the platform where the 
agent resides. Furthermore, this protocol allows to save up network bandwidth because 
the agent code is only sent in case that the destination platform does not have a copy of 
it. 
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Fig. 5: Push Transfer Diagram. 



The protocol is divided in two stages (see Figure[3]l. In the first stage a code unique 
identifier (CID) value (generated by a cryptographic hash function) is sent to ask whether 
the agent code transfer is needed. In the second stage, the code, the agent data, and the 



agent state (when it is needed) are sent. The ontology used in this protocol is called 
"push-transfer-protocol-ontology-v 1 ". 

The first part uses an IEEE-FIPA Proposal Interaction Protocol [5] (see Figure[3]l. 
The first message sent contains a negotiate predicate (see that on Tabled with the 
code unique identification (CID) value (see Table |5j. Then a response message shall 
be received accepting the proposal to send the code or rejecting it. In case of error, the 
proposal is rejected and an error is included as a message content. 



Predicate 


negotiate 


Ontology 


push-transfer-protocol-ontology-vl 


Supported by 


amm 


Description 


Propose to negotiate whether send the agent code to the destination platform. 


Domain 


push-transfer-protocol-negotiate 



Table 4: Push Transfer Protocol Ontology: Negotiate predicate. 



Frame 


push-transfer-protocol-negotiate 


Ontology 


push-transfer-protocol-ontology-vl 


Parameter 


Description 


Presence 


Type 


cid 


Agent code unique identifier (CID) 


Optional 


String 



Table 5: Push Transfer Protocol Ontology: negotiate transfer. 



The second part uses a simplified FIPA Request Interaction Protocol |6| (see Fig- 
uref2]i. The first message sent contains a transfer action (as seen in Tabled with 
the code, data and/or state of the migrating agent (see Table |7). It must be noted that 
the code, data and state are packed according to the specific mobile agent system. For 
example, in a JADE system the code is placed inside a JAR file, the data is on a byte ar- 
ray resulting from the Java agent object serialisation, and the state is not used. Once the 
agent is transferred, the sending platform expects to receive an inf orm-done mes- 
sage, if the agent has been correctly installed in the destination platform, or a failure, 
otherwise. 



Function 


transfer 


Ontology 


push-transfer-protocol-ontology-vl 


Supported by 


amm 


Description 


Request to send the agent code and instance to the destination platform. 


Domain 


push-transfer-protocol-transfer 



Table 6: Push Transfer Protocol Ontology: Transfer action. 



Frame 


push-transfer-protocol-transfer 


Ontology 


push-transfer-protocol-ontology-vl 


Parameter 


Description 


Presence 


Type 


cid 


Agent code unique identifier (CID) 


Optional 


String 


code 


Agent code 


Optional 


Byte-Stream 


data 


Agent data 


Mandatory 


Byte-Stream 


state 


Agent state 


Optional 


Byte-Stream 



Table 7: Push Transfer Protocol Ontology: transfer agent. 



5 Conclusions 



Mobile agent systems require new open and interoperable mechanisms for migration. 
In order to face this problem, we have presented a new open architecture for the future 
standardisation of agent migration based on several IEEE-FIPA agent specifications. 

This architecture splits the migration process into three steps (Pre-Transfer, Trans- 
fer, and Post-Transfer), with a flexible open set of protocols in each step, plus two ad- 
ditional fixed steps (Agent Registration and Agent Power Up), each one implemented 
by an already defined protocol. The concrete protocols for the first three steps are de- 
liberately left unspecified so that the architecture can accommodate a wide range of 
protocols and strategies. The most important of these three steps is the Transfer, actu- 
ally the only one required among the three of them. As an example of Transfer protocol 
we have also presented the Push Transfer Protocol. 

To demonstrate the feasibility of our proposal, we have successfully implemented 
and tested it in two different agent platforms: JADE and AgentScape. In the case of the 
JADE agent platform, the new migration architecture is the evolution of the former mi- 
gration service [ 1 1. This can be downloaded from the JIPMS SourceForge project web- 
site (http : / / jipms . sourcef orge . net) as from the development release 1.98. 
The proposed migration has also been implemented into the AgentScape platform, once 
it has been successfully tested in JADE. This has involved the implementation of sev- 
eral FIPA specifications because AgentScape is not a FIPA compliant platform. These 
implementations prove that the proposed architecture is valid for completely different 
agent platforms. 

Despite that these two platforms have the same migration architecture, agents can- 
not move between them because the agent Application Programming Interfaces are 
different and, therefore, incompatible. As a future work, part of our research will be 
focused on migrating and running agents from a specific platform technology to a dif- 
ferent one. The first step, that is, the definition of mobility interoperable mechanisms 
for different platforms, has already been solved by this proposal. 

Furthermore, another future work will be the research on new protocols, like new 
migration schemes (on demand migration, fragmented migration, ...), authentication 
and authorisation mechanisms, agent results transferring, etc., all of them implementa- 
ble in one of the first three steps of the migration proposal. 
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